The development and release of a software product, such as operating systems or operating system components, application programs, plug-ins, and scripts, by a software vendor involves testing and quality assurance to remove errors such as inconsistencies and bugs from the software product before it is released. Testing may be based on use of the software product in an intended way and in an intended environment. Following a release of a software product, however, the software product may be used in ways that were not tested. Despite pre-release testing, then, errors may arise in the software product.
The software vendor, having an interest in releasing and supporting error-free products, may attempt to diagnose and correct the error by analyzing conditions of the software product when the error occurred. Accordingly, when a failure does occur as a result of an error, a user of the software product may be prompted to upload information about the software product and the failure to the software vendor. This information may be contained in an error report, which may contain any useful information about the circumstances of the failure of the software product, including information about the failure itself, information about the software product, and/or information about the computing device on which the software product was executing at the time of the failure. If the user consents to uploading information about the failure, an error report may be generated, uploaded to an error reporting service, and analyzed to determine an error that is the source of the failure and a solution to the error.
Examples of such error reporting services are the Windows Error Reporting (WER) service and the Online Crash Analysis (OCA) service offered as a part of the Windows® operating system available from the Microsoft® Corporation of Redmond, Wash. In the WER service, when the Windows® operating system detects that a software product has experienced a failure, the operating system may capture some information about the state of the software product and/or the operating system at the time of the failure, package the information into a WER report, and transmit the report to Microsoft® to be analyzed such that the error can be diagnosed and corrected.
Error reports may comprise various types of information regarding a failure. For example, a failure type may be included in the error report that identifies how a software product failed as a result of the error. The failure type could be a crash, a hang, or a deadlock, among others. If the failure is a crash, then the error report may also contain an exception code identifying the type of crash. Further, the error report may include information about the software product that failed, such as a process name for the executing process that failed (i.e., the instantiation of the software product that was executing at the time) and a callstack for the process.
A callstack is maintained by a computer executing a process and identifies information about a state of the computer during execution of the process. A separate callstack is maintained for each process that is run simultaneously. For example, for each function executed by the process, the callstack includes an entry (called a “frame”) identifying the code module (e.g., library or file) containing the function, the function's name, and input parameters and/or output parameters that have been calculated while executing the function. When a first executing function calls a second function, a new frame is created in the callstack for the second function and a current address in memory (the “offset”) for the first function, the address at which the instruction to execute the second function is located, is stored in the frame for the first function. When a function is completed, its frame is removed from the callstack and the process returns to the offset indicated for the next function, to complete processing of that next function. In this way, the callstack maintains a history of execution of the process, through various functions, as the process is executing. When an error report is generated following a failure, at least a portion of the callstack may be included in the error report.
When an error reporting service receives an error report regarding an error that occurred in a software product, the error report may be assigned to a software developer for review. The developer may diagnose the error by determining a source of the error and may produce a solution to the error, which may include modifying the software product.
When a software product is widely released, and that software product experiences an error, it is likely that many instances of the software product in use by different users and/or different computers may generate the same error. If each of those instances transmits an error report using an error reporting service, then there may be a great deal of redundancy in the error reports received by the error-reporting service. This redundancy may lead to inefficiencies in the processing of error reports and in the diagnosing and correcting of errors identified by the error reports. If two developers at a software vendor both receive an error report that identifies the same error and both begin work on diagnosing and correcting the error, then the work is duplicated.